PC Welt 1997 July

home *** CD-ROM | disk | FTP | other *** search

/ PC Welt 1997 July / Freeware CD.iso / FREEWARE / !utils / sfs / SFS117!.EXE / SFS6.DOC < prev next >

Wrap

Text File | 1995-03-20 | 67.3 KB | 1,167 lines

Politics -------- Many governments throughout the world have an unofficial policy on cryptography which is to reserve all knowledge and use of encryption to the government in general and the elite in particular. This means that encryption is to be used firstly (in the form of restrictions on its use) for intelligence-gathering, and secondly for protecting the secret communications of the government. The government therefore uses encryption to protect its own dealings, but denies its citizens the right to use it to protect their own privacy, and denies companies the right to use it to protect their business data. Only a very small number of countries have laws guaranteeing citizens' rights to use encryption[1]. Some countries have no explicit laws covering encryption, but have governments which support the use of encryption by their citizens[2]. This policy is enforced in many ways. In the US it is mainly through the use of the ITAR, the International Traffic in Arms Regulations, a law which was passed without public debate during the second world war. This defines all encryption material (hardware and software) as "munitions", subject to special governmental control[3]. France also classifies encryption devices as munitions[4]. These "munitions" in fact have no violent use beyond perhaps beating someone to death with a box of disks. Their only possible use is to protect personal privacy and the privacy of business data. In limiting the use (and export) of encryption technology[5], the US (and many other countries which follow the lead of the US) are not only denying their citizens the means to ensure the privacy of personal information stored on computer, they are also placing businesses at risk. With no easy way to protect their data, companies are losing billions of dollars a year to industrial espionage which even a simple measure like SFS would help to reduce. Some real-life examples of what the lack of secure encryption can do are: - The head of the French DGSE (Direction Generale de la Securite Exterieure) secret service has publicly boasted that his organisation, through industrial espionage, helped French companies acquire over a billion dollars worth of business deals from foreign competitors [6][7]. - In a talk given to the Executives' Club of Chicago on 17 March 1994 by FBI Director Louis Freeh, he stated that: "a nation's power is increasingly measured by economic prosperity at home and competitiveness abroad. And in some ways, the United States is a sitting duck for countries and individuals who want to take a short cut to power" [At least 20 nations are] "actively engaged in economic espionage" "This kind of information [cost and price structure, research and development results, marketing plans, bids and customer lists] can be intercepted from fax and satellite communications. It can be monitored from cellular and microwave telephone links. It can be retrieved from inadequately protected computer systems". - A laptop stolen from Wing Commander David Farquhar on December 17th 1990 supposedly contained extremely sensitive information related to British military operations against Iraq during the Gulf War. This information was known and published outside the UK, but was not published in the UK due to censorship until The Irish Times ran a story on it in the January 3rd 1991 issue. More information was finally disclosed on January 9th 1991 when Associated Press threatened to run the story anyway. The laptop was supposed to contain highly sensitive military plans, but no steps had been taken to protect the information. - Volume 10, Issue 77 of the RISKS-Forum Digest, published on 11 January 1991, reported that thieves in the Soviet Union had stolen a computer used to handle Russian internet traffic. Although the target of the theft was the computer hardware, the thieves also acquired all the private mail held on the machine as plain text files. - The book "Friendly Spies" by Peter Schweitzer, published by Atlantic Monthly Press, gives many accounts about covert intelligence operations directed against US corporations by cold war allies, with foreign governments conspiring with foreign companies to steal US technology and economic secrets. In 1988, the University of Illinois published a document titled "A Study of Trade Secrets in High Technology Industries" which revealed that 48% of all companies surveyed admitted to being the victims of some form of inustrial espionage. - In a talk given to the National Press Club on 3 April 1990 by Senator David Boren, he warns that: "An increasing share of the espionage directed against the United States comes from spying by foreign governments against private American companies aimed at stealing commercial secrets to gain a national competitive advantage". - Volume 14, Issue 34 of the RISKS-Forum Digest, published on 22 February 1993, reports that "France and Germany and many other countries require US companies to `register' their encryption keys for reasons of national security. All of the American transmissions are monitored and the data is passed on to the local competitors. Companies like IBM finally began to routinely transmit false information to their French subsidiary just to thwart the French Secret Service and by transitive property of economic nationalism, French computer companies". - Markt und Technik, 18/94, page 49, in a discussion of US monitoring stations in Germany, reports that "powerful computers scan telephone, fax, and computer data traffic for information from certain sources, to certain destinations, or containing certain keywords, and store any interesting communications for later analysys. The fear that such monitoring stations will, after the end of the cold war, be used for industrial espionage, has been expressed by DP managers and tacitly confirmed by US security agencies". - Directorate T (for "technology") of the KGB has three main aims, two of which relate to the acquisition of military intelligence on enemies of the (former) USSR, and the third of which is "Acceleration of Soviet scientific and technical progress by acquiring information and samples of equipment"[8]. Since the collapse of the Soviet Union, the use of the KGB for industrial espionage has increased dramatically. A great many other countries now use the idle capacity of their intelligence agencies for industrial espionage purposes. - A US company was being consistently underbid by a Japanese competitor which was intercepting their electronic traffic. When they started encrypting their messages, the underbidding stopped. A few days later they were requested by the US government to stop using encryption in their traffic[9]. - A New Zealand computer dealer acquired 90 used disks which turned out to contain sensitive financial records from a large bank. The evening after he turned them over to the bank (for a $15,000 cash "finders fee") he was killed in a road accident. The finders fee was never recovered[10]. Despite this major security problem, the bank wouldn't learn from their mistakes. A few weeks later a large-capacity disk drive from a network server which was originally used by them was supplied to another company as a supposedly "new" replacement for a drive which had died. This drive was found to contain the complete financial records from one of their branches. Not wanting to be scraped off the side of the road one night, the system manager decided to erase the contents of the drive[11]. It isn't known how many more of their confidential financial records this bank has handed out to the public over the years. - National Security Decision Directive 42, signed by President Bush in 1990, notes that "telecommunications and information processing systems are highly susceptible to interception, unauthorized access, and related forms of technical exploitation as well as other dimensions of the foreign intelligence threat. The technology to exploit these electronic systems is widespread and is used extensively by foreign nations and can be employed as well by terrorist groups and criminal elements"[12]. - A customer of an electrical goods retail store in the UK returned a defective PC to the store, asking them to erase the contents of the hard drive which contained confidential information. Six months later he received a phonecall from someone who had purchased his old computer from the store, complete with the confidential information he had wanted erased - like the previous case, the customer had been sold a supposedly new machine which still held data left there by the previous owner[13]. - The New Zealand Securities Commission accidentally left a number of sensitive files on the hard drive of one of a group of machines which was later sold at auction for $100. These files were stored without any security measures, and related to Securities Commission and Serious Fraud Office investigations. They were recovered about a week later, but not before the press had got to them[14]. - In a report on the front page of "Infotech Weekly", Issue 157, 15 August 1994, a systems analyst says he knows of dozens of cases of confidential information being given away when old equipment is disposed of, including "three alone during the past six months when commercially-sensitive or just plain embarassing material was passed on inadvertently". A particularly widespread problem seems to be the improper disposal of backup disks full of confidential records[15]. - The owner of a notebook computer which had stopped working asked a visiting computer instructor to take a look at it. The instructor determined that he could fix it with the Norton Utilities, which he had back at his office. The companies network administrator, who also had a copy of the Norton Utilities, offered to fix it on the spot to save taking the computer offsite. The notebook's hard drive contained the network administrators dismissal papers. Luckily the instructor was able to retrieve the notebook before any damage was done[16]. - The book "By Way of Deception" by Victor Ostrovsky and Claire Hoy, published by St. Martins Press, New York, in 1990 (ISBN 0-312-05613-3), reports in Appendix I that Mossad's computer services routinely monitor VISA, AMEX, and Diner's Club transactions, as well as police computer traffic. - An international banker travelled to Latin America with information on various contacts there stored on his laptop. His hotel room was broken into and the computer stolen, along with all the client information. Luckily the thieves were after the hardware rather than the software, as the information stored in the machine could have caused serious problems for the people involved[17]. In the case of the bank selling its financial records the lack of encryption not only had the potential to cause serious financial harm to the bank involved but resulted in the death of the main player. The use of a program like SFS would have made the contents of the disks unreadable to anyone but the bank. In 1991 the US Justice Department tried to introduce legislation that would require all US digital communications systems to be reengineered (at enormous cost) to support monitoring of message traffic by the FBI. This measure was never passed into law. The next year the FBI tried to introduce a similar measure, but could find no-one willing to back the bill. In 1993, yet another attmempt was made, which is currently being fought by an unusual coalition of civil libertarians, computer users and companies, and communications providers. A poll carried out by Time/CNN in March 1994 indicated that 2/3 of Americans were opposed to the legislation[18]. It was finally passed on 7 October 1994 as the Digital Telephony Act[19]. In April 1993, the US government announced a piece of hardware called the Clipper Chip. They proposed that this device, whose details are classified and which contains self-destruct mechanisms which are activated if attempts are made to examine it too closely, be built into all telephones. Each chip has a special serial number which identifies all communications carried out with that phone. At the beginning of each transmission, telephones equipped with a Clipper Chip negotiate a connection which involves sending identifying information across the phone network, and setting up a common key to use for encrypting the conversation. Built into this setup is a special back door which allows the government, and anyone who works for the government, and anyone who has a friend who works for the government, and anyone with enough money or force to bribe or coerce the aforementioned people, to monitor the conversation[20]. The job is made much easier by the extra identification information which the Clipper Chip attaches to the data stream. The Clipper Chip allows monitoring on a scale even George Orwell couldn't have imagined when he wrote his novel "1984"[21 US government prefers to call the mechanism used by Clipper a key escrow system, it is in fact a key forfeiture system in that all hope of privacy is forfeited to the government. The Time/CNN poll mentioned above found that 80% of Americans were opposed to the Clipper Chip[18][22]. The Clipper Chip is also susceptible to an attack in which a fake Clipper-encrypted message can be created without needing to know the encryption keys, allowing either false evidence to be created, or allowing genuine evidence to be discounted on the basis that it might have been faked[23]. A somewhat less blatant attempt to bypass communications privacy is gradually appearing in the rest of the world. The GSM digital telephone system uses a special encryption algorithm called A5X which is a modified form of a stronger system called A5. A5X exists solely as a deliberately crippled A5, and is relatively easy to bypass for electronic monitoring purposes. Although the details of A5 are classified "for national security purposes"[24], various sources have commented that even the original unmodified A5 probably provides only limited security against a determined attack, and the actual implementation exhibits some fundamental flaws (such as a 3-hour key rollover) which can greatly aid an attacker[25][26]. It is against this worrying background that SFS was created. Right from the start, the idea behind SFS was to provide the strongest possible cryptographic security. No compromises were made, there are no back doors or weaknesses designed into the system, nor will there ever be the deliberate crippling of the system or undermining of its integrity which some organizations would like. The algorithms and methods used in SFS have been selected specifically for their acknowledged strength and general acceptance by the worldwide cryptographic community, and conform to a wide variety of national and international standards for secure encryption. As new algorithms and cryptographic processes appear, SFS will be updated to always provide the best possible security available. Footnote [1]: One of these is Japan. Article 21 of the Japanese Consitution states: "Freedom of assembly and association as well as speech, press, and all other forms of expression are guaranteed. No censorship shall be maintained, nor shall the secrecy of any means of communication be violated". Footnote [2]: The only known UK government statement on the use of encryption is in the record of parliamentary debates (Hansard) for Thursday 21st April 1994 and consists of a written answer to a question posed by an MP: Mr. Llew Smith: To ask the Secretary of State for the Home Department what is Her Majesty's Government's policy towards the use of private encryption technology by individuals or companies to protect data sent by electronic mail. Mr. McLoughlin: I have been asked to reply. It is a matter for the individual, or company, to take measures, which may include private encryption technology, which they consider necessary to safeguard their electronic mail communication. Footnote [3]: The ITAR, 22 CFR commencing with section 120, has provisions in section 121.1, under Category XII (b) that "cryptographic devices and software" are considered to be defense articles subject to the State Department's Office of Defense Trade Controls authority with respect to export. Footnote [4]: The "decret du 18 avril 1939" defines 8 categories of arms and munitions from the most dangerous (1st category) to the least dangerous (8th category). The "decret 73-364 du 12 mars 1973" specifies that encryption equipment belongs to the second category. Any usage of such equipment requires authorization from the Prime Minister. The "decret 86-250 du 18 fev 1986" extends the definition of encryption equipment to include software. It specifies that each request for authorization for business or private usage of the equipment must be sent to the Minister of Telecommunications. The request must include a complete and detailed description of the "cryptologic process", and if this is materially possible, of two copies of the envisaged equipment (see also Footnote 6). The "loi 90-1170 du 29 decembre 1990" states that export or use of encryption equipment must be previously declared when used only for authentication, and previously authorized by the Prime Minister in all other cases, with penalties of fines of up to 500 000F and three months in jail. Import of encryption equipment (but not encrypted data) is prohibited by the "decret du 18 avril 1939", article 11. However the "loi du 29 dec 1990" only restricts use or export, not import, of encryption equipment. There are no restrictions on the import of encrypted data. Information on the (questionable) need to license encryption is available via FTP from ftp.urec.fr in the directory /pub/securite/Divers as autorisation.utilisation.crypto. In general, these laws appear not to be enforced, with encryption software being freely imported, exported, available, and used in France. Footnote [5]: The reasoning behind this, as stated by the Permanent Select Committee on Intelligence in its commentary of 16 June 1994 on the HR.3937 Omnibus Export Administration Act is that "the intelligence community's cryptologic success depends in part on controlling the use of encryption [...] controlling the dissemination of sophisticated encryption has been and will continue to be critical to those successes [of the US intelligence community] and US national security interests". Footnote [6] This was reported by cryptographer Martin Hellman at the 1993 RSA Data Security conference on 14-15 January 1993. Footnote [7]: "If someone steals from your computer, you probably won't know it. You may find yourself losing customers, or market share, or your ideas may show up in unexpected places" - Mark Rasch, a lawyer who specialises in computer crime at the Washington law firm Arendt, Fox, Kintner, Plotkin, and Kahn, quoted in "InfoTech Weekly", Issue 168, 31 October 1994, page 10. Footnote [8]: The industrial espionage practices of Soviet intelligence agencies is discussed in more detail in "Soviet Industrial Espionage", which appeared on page 25 of the April 1987 edition of the Bulletin of the Atomic Scientists. Footnote [9]: Private communications from one of the people involved. Footnote [10]: This event received nationwide TV, radio, and newspaper coverage at the time. For example, any New Zealand paper published on 7 September 1992 should provide more information. Footnote [11]: Private communications from the system manager involved. Footnote [12]: Postions of NSDD-42 were declassified on 1 April 1992 through the efforts of Marc Rotenberg of the Computer Professionals for Social Responsibility. Footnote [13]: This was reported on "Watchdog", a BBC consumer affairs television program screened on Monday 26th September 1994. Footnote [14]: This event received nationwide TV, radio, and newspaper coverage at the time. Most New Zealand papers published on 13 August 1994 contain coverage of the story. Mention of the return of the files was made about a week later. Footnote [15]: A computer trader who buys machines at auction for reconditioning and later resale says "the amount of stuff we find on the machines we handle is incredible. You don't need to do any fancy bugging of a companies offices to get at their business records, all you need to do is buy their old computers. Occasionally they'll go as far as reformatting the drives, which won't slow anyone down for more than 10 minutes". Footnote [16]: This was discussed in the alt.folklore.computers newsgroup on 7 March 1995, message-ID <3jgv90$74q@huey.cadvision.com> Footnote [17]: This was discussed in the alt.privacy newsgroup on 7 January 1995, message-ID <3el7ju$gt3@pipe1.pipeline.com>. Footnote [18]: "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it" - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, 14 March 1994. Footnote [19]: On 7 October 1994 the US Congress passed the HR 4922/SR 2375 Digital Telephony Act, which was signed into law as the Communications Assistance for Law Enforcement Act on 25 October. This requires telecommunications carriers to modify existing equipment and design new equipment to facilitate monitoring of communications by law enforcement agencies. Footnote [20]: In June 1994, an AT&T researcher discovered a means of bypassing this monitoring using about 28 minutes of computation time on easily-available mass-market Tessera (now renamed to Fortezza[25][26][27]) cards. By precomputing the values or employing many such devices running in parallel, the time can be reduced to virtually nothing. This attack also opened up a number of other interesting possibilities for generally bypassing many of the perceived undesirable "features" of Clipper. Footnote [21]: It has been claimed that the Clipper proposal is an example of the government servicing the people in the sense of the term used in the sentence "The farmer got a bull to service his cows". Footnote [22]: In December 1994, the ANSI X9 committee rejected Clipper in favour of a triple-DES based security standard, for reasons summed up in a letter by Electronic Frontiers Foundation board member John Gilmore: "NSA's opposition to triple-DES appears to be an indirect attempt to push Clipper by eliminating credible alternatives. Clipper is not a viable alternative to triple-DES, and carries substantial liabilities. There has been no evidence of foreign acceptance of the standard and the Skipjack algorithm is classified. The likelihood of any government accepting secret standards developed by a foreign security agency is slim. Clinton Administration efforts, through the NSA, to push Clipper as a domestic standard over the past two years have failed". Footnote [23]: In the December 1994 "Communications of the ACM", page 12, Mark Lomas and Michael Roe demonstrate an attack which takes advantage of the fact that the data to be encrypted is exclusive-ored with a pseudorandom key stream, so that by exclusive-oring the data back in the original key stream can be recovered. At this point any arbitrary data can be exclusive-ored into the key stream to create a forged encrypted message. No knowledge of the encryption key is necessary in order to perform this attack. Footnote [24]: In June 1994, the statement that A5 was too strong to disclose was suddenly changed so that it now became too weak to disclose, and that discussing the details might harm export sales. This is an interesting contrast to the position taken in 1993 that sales to the Middle East might end up providing A5-capable equipment to the likes of Saddam Hussein. Apparently there was a major debate among the NATO signal agencies in the 1980's over whether the GSM encryption should be strong or weak, with the weak encryption side eventually winning. Footnote [25]: It has been reported that GCHQ, the UK intelligence agency which requested the A5X changes, regards as "strong encryption" (and therefore not suitable for use by the public) anything which can't be broken in real time. Footnote [26]: UK cryptographer Ross Anderson has charecterised A5 as being "not much good". A simple brute-force attack which searches all 2^40 key combinations will break the system in about a week on a standard PC, with much faster attacks being possible using either better algorithms, custom hardware, or both. Interestingly, the low upper limit on the number of possible keys would also seem to meet the US government requirements for weak exportable encryption. Attacks faster than the basic brute-force one are also possible, and one such attack was to be presented by Dr Simon Shepherd at an IEE colloquium in London on 3rd June 1994. However the talk was canceled at the last minute by GCHQ. An A5 cracking chip is currently being designed by a student for his MSc thesis. Footnote [27]: "Violins, the music says fortezza, not forte". Footnote [28]: "Police have confirmed that the body found floating in the East River late last night belonged to Joey "No Ears" Fortezza, a well-known family man". Footnote [29]: "Will sir be having wine with his spaghetti al fortezza?". An Introduction to Encryption Systems ------------------------------------- For space reasons the following introduction to encryption systems is very brief. Anyone requiring more in-depth coverage is urged to consult the texts mentioned in the references at the end of this document. Encryption algorithms (ciphers) are generally one of two types, block ciphers and stream ciphers. A block cipher takes a block of plaintext and converts the entire block into ciphertext. A stream cipher takes a single bit or byte of plaintext at a time and converts it into ciphertext. There also exist means of converting block ciphers to stream ciphers, and vice versa. Usually a stream cipher is preferred, as it doesn't require data to be quantised to the block size of the cipher in use. Unfortunately, stream ciphers, although more convenient, are usually harder to get right than block ciphers. Many practical stream ciphers are in fact simply block ciphers pretending to be stream ciphers. Virtually all good conventional-key ciphers are so-called product ciphers, in which several (relatively) weak transformations such as substitution, transposition, modular addition/multiplication, and linear transformation are iterated over a piece of data, gaining more and more strength with each iteration (usually referred to as a round). These types of ciphers have been extensively studied and are reasonably well understood. The following table compares the main parameters of several product ciphers. Lucifer is the immediate precursor to the US Data Encryption Standard (DES). Loki is a proposed alternative to DES. FEAL is a fast block cipher designed in Japan. IDEA is a relatively new Swiss block cipher which has been proposed as a successor to DES and which has (so far) proven more resistant to attack then DES. MDC/SHS is a cipher based on the SHS one-way hash function (more on this later). +-----------+------------+----------+-----------+---------------+ | Cipher | Block size | Key size | Number of | Complexity of | | | | (bits) | rounds | Best Attack | +-----------+------------+----------+-----------+---------------+ | Lucifer | 128 | 128 | 16 | 2^21 | | DES | 64 | 56 | 16 | 2^43 | | Loki91 | 64 | 64 | 16 | 2^48 | | FEAL-8 | 64 | 128 | 8 | 10,000 | | IDEA | 64 | 128 | 8 | 2^128 | | MDC/SHS | 160 | 512 | 80 | 2^512 | +-----------+------------+----------+-----------+---------------+ The complexity of the best known attack is the number of operations necessary to allow the cipher to be broken. Note how the block size, key size, and number of rounds don't necessarily give a good indication of how secure the algorithm itself is. Lucifer, although it has twice the block size and over twice the key size of DES, is rather simple to break (the key size of DES is discussed a little further on in this section). DES is the result of several years of work on improvements to Lucifer. FEAL has been continually changed every year or so when the previous version was broken. Due to this, current versions are treated with some scepticism. Both IDEA and MDC have so far resisted all forms of attack, although recently a class of weak keys have been discovered in IDEA, but this problem was quickly corrected with a simple change in the key setup process. Note that in the case of the last two algorithms the given complexity is for a brute-force attack (explained below), which is the most pessimistic kind possible. There may be much better attacks available, although if anyone knows of any they're not saying anything. Of the algorithms listed above, DES has been attacked the hardest, and IDEA and MDC the least, which may go some way toward explaining the fact that brute force is the best known attack. There are a large number of modes of operation in which these block ciphers can be used. The simplest is the electronic codebook (ECB) mode, in which the data to be encrypted is broken up into seperate subblocks which correspond to the size of the block cipher being used, and each subblock is encrypted individually. Unfortunately ECB has a number of weaknesses (some of which are outlined below), and should never be used in a well-designed cryptosystem. Using P[] to denote a plaintext block, C[] to denote a ciphertext block, e() to denote encryption, d() to denote decryption, and ^ for the exclusive-or operation, ECB mode encryption can be given as: C[ n ] = e( P[ n ] ) with decryption being: P[ n ] = d( C[ n ] ) When used to encrypt and decrypt multiple blocks of data, this looks as follows: + - - - - - - - - - - - - - - - - - - - - + +---------+ +---------+ +---------+ | | Block 1 | | Block 2 | | Block 3 | | +---------+ +---------+ +---------+ | | | | | v v v | +---------+ +---------+ +---------+ | Key ---->| Encrypt |--| Encrypt |--| Encrypt | Encryption | +---------+ +---------+ +---------+ | | | | | v v v | +---------+ +---------+ +---------+ | | | | | | | | +---------+ +---------+ +---------+ + - - - | - - - - - -|- - - - - - | - - - + | | | + - - - v - - - - - -v- - - - - - v - - - + +---------+ +---------+ +---------+ | | | | | | | | +---------+ +---------+ +---------+ | | | | | v v v | +---------+ +---------+ +---------+ | Key ---->| Decrypt |--| Decrypt |--| Decrypt | Decryption | +---------+ +---------+ +---------+ | | | | | v v v | +---------+ +---------+ +---------+ | | Block 1 | | Block 2 | | Block 3 | | +---------+ +---------+ +---------+ + - - - - - - - - - - - - - - - - - - - - + Since each block of data is encrypted seperately, two identical blocks of plaintext will encrypt to give the same ciphertext, and encrypted blocks can be moved around or deleted without affecting the outcome of the decryption process. A better encryption mode is cipher block chaining (CBC), in which the first data subblock is exclusive-ored with an initialization vector (IV) and then encrypted. The resulting ciphertext is exclusive-ored with the next data subblock, and the result encrypted. This process is repeated until all the data has been encrypted. Because the ciphertext form of each subblock is a function of the IV and all preceding subblocks, many of the problems inherent in the ECB encryption mode are avoided. CBC-mode encryption is: C[ 1 ] = e( P[ 1 ] ^ IV ) C[ n ] = e( P[ n ] ^ C[ n-1 ] ) and decryption is: P[ 1 ] = d( C[ 1 ] ) ^ IV P[ n ] = d( C[ n ] ) ^ C[ n-1 ] When used to encrypt and decrypt multiple blocks of data, this looks as follows: + - - - - - - - - - - - - - - - - - - - - - - - - - - - + +---------+ +---------+ +---------+ +---------+ | | IV | | Block 1 | | Block 2 | | Block 3 | | +---------+ +---------+ +---------+ +---------+ | | | | | | +---------> XOR +---> XOR +---> XOR | | | | | | | v | v | v | +---------+ | +---------+ | +---------+ | Key ----------------->| Encrypt |-|-| Encrypt |-|-| Encrypt | Encryption | +---------+ | +---------+ | +---------+ | | | | | | | v | v | v | +---------+ | +---------+ | +---------+ | | |-+ | |-+ | | | +---------+ +---------+ +---------+ + - - - - - - - - - -|- - - - - - -|- - - - - - -|- - - + | | | + - - - - - - - - - -v- - - - - - -v- - - - - - -v- - - + +---------+ +---------+ +---------+ +---------+ | | IV | | |-+ | |-+ | | | +---------+ +---------+ | +---------+ | +---------+ | | | | | | | | | v | v | v | | +---------+ | +---------+ | +---------+ | Key ----------|------>| Decrypt |-|-| Decrypt |-|-| Decrypt | Decryption | | +---------+ | +---------+ | +---------+ | | | | | | | | | v | v | v | | +---------+ | +---------+ | +---------+ | | | | | | | | | | | | +---------+ | +---------+ | +---------+ | | | | | | | | +---------> XOR +---> XOR +---> XOR | | | | | | v v v | +---------+ +---------+ +---------+ | | Block 1 | | Block 2 | | Block 3 | | +---------+ +---------+ +---------+ + - - - - - - - - - - - - - - - - - - - - - - - - - - - + Each block of data is now chained to the previous and next block, making it difficult to insert or switch blocks, and hiding the fact that different encrypted blocks may contain the same plaintext. By using a unique, random IV, otherwise identical messages can be encrypted to give different ciphertexts. Another encryption mode is cipher feedback (CFB), in which the IV is encrypted and then exclusive-ored with the first data subblock to provide the ciphertext. The resulting ciphertext is then encrypted and exclusive-ored with the next data subblock to provide the next ciphertext block. This process is repeated until all the data has been encrypted. Because the ciphertext form of each subblock is a function of the IV and all preceding subblocks (as is also the case for CBC-mode encryption), many of the problems inherent in the ECB encryption mode are avoided. CFB-mode encryption is: C[ 1 ] = P[ 1 ] ^ e( IV ) C[ n ] = P[ n ] ^ e( C[ n-1 ] ) and decryption is: P[ 1 ] = C[ 1 ] ^ e( IV ) P[ n ] = C[ n ] ^ e( C[ n-1 ] ) This encryption mode converts a block cipher into a stream cipher in which data is processed as a stream of bits or bytes rather than a collection of blocks: + - - - - - - - - - - + + - - - - - - - - - - + +---------------+ Initial | +---------+ | Initial | | +---------+ | | value ------->| |<-+ value -----|->| |<-+ from IV | +---------+ | | from IV | | +---------+ | | | | | | v | | | | v | +---------+ | | +---------+ Key --------->| Encrypt | | | Key -------|->| Encrypt | | +---------+ | | +---------+ | | | | | | | | v | | v | +---------+ | | | | +---------+ | | | | | | | | +---------+ | | | | +---------+ | | | | | Data -----------> XOR -----+-------------------+----> XOR -----------> Data + - - - - - - - - - - + + - - - - - - - - - - + Encryption Decryption One interesting feature of this mode of encryption is that there is no need for a decrypt primitive, since both CFB encryption and CFB decryption only make use an encrypt primitive. This means that CFB encryption can be implemented with non-reversible functions such as the SHS algorithm used for MDC/SHS. There are several other modes of operation for block ciphers which are not covered here. More details can be found in the texts given in the references. One point worth noting is that by using a different IV for each message in CBC and CFB mode, the ciphertext will be different each time, even if the same piece of data is encrypted with the same key. This can't be done in ECB mode, and is one of its many weaknesses. There are several standard types of attack which can be performed on a cryptosystem. The most restricted of these is a ciphertext-only attack, in which the contents of the message are unknown. This kind of attack virtually never occurs, as there is usually some regularity or known data in the message which can be exploited by an attacker. This leads to the next kind of attack, the known-plaintext attack. In this case some (or all) of the plaintext of the message is known. This type of attack is a lot more common than it would seem, since much data consists of well-known, fixed-format messages containing standard headers, a fixed layout, or data conforming to a certain probability distribution such as that of ASCII text. Finally, in a chosen-plaintext attack the attacker is able to select plaintext and obtain the corresponding ciphertext. This attack, which involves fooling the victim into transmitting a message or encrypting a piece of data chosen by the attacker, is somewhat more tricky to mount, but can often be performed with a little work. For example, it was used to help break the Japanese "Purple" cipher during WWII by including in a news release a certain piece of information which it was known the Japanese would encrypt and transmit to their superiors. However attacks of this kind are usually entirely unnecessary. Too many cryptosystems in everyday use today are very easy to break, either because the algorithms themselves are weak, because the implementations are incorrect, or because the way they are used is incorrect. Often amateurs think they can design secure systems, and are not aware of what an expert cryptanalyst could do. Sometimes there is insufficient motivation for anybody to invest the work needed to produce a secure system. Many implementations contain flaws which aren't immediately obvious to a non-expert. Some of the possible problems include: - Use of easily-searched keyspaces. Some algorithms depend for their security on the fact that a search of all possible encryption keys (a so-called brute force attack) would take too long to be practical. Or at least, it took too long to be practical when the algorithm was designed. The Unix password encryption algorithm is a prime example of this. The DES key space is another example. Recent research has indicated that the DES was not in fact weakened by having only 56 bits of key material (as has often been claimed), since the inherent strength of the algorithm itself only provides this many bits of security (that is, that increasing the key size would have no effect since other attacks which don't involve knowing the key can be used to break the encryption in far less than 2^56 operations). The encryption used in the Pkzip archiver can usually be broken automatically in less time than it takes to type the password in for authorized access to the data since, although it allows longer keys than DES, it makes the check for valid decryption keys exceedingly easy for an attacker. - Use of insecure algorithms designed by amateurs. This covers the algorithms used in the majority of commercial database, spreadsheet, wordprocessing, and miscellaneous utility programs such as Ami Pro, Arc, Arj, Lotus 123, Lotus Symphony, Microsoft Excel, Microsoft Word, Novell Netware, Paradox, Pkzip, Quattro Pro, WordPerfect, and many others. These systems are so simple to break that the author of at least one package which does so added several delay loops to his code simply to make it look as if there was actually some work involved. In addition, some programs which claim to use encryption or some related form of security for protection rely instead on a simple password check which can be easily bypassed. Example of this are Fastback, Microsoft Money, Norton's partition security system, Quicken, and Stacker. - Use of insecure algorithms designed by experts. An example is the standard Unix crypt command, which is an implementation of a rotor machine much like the German Enigma cipher which was broken during WWII. There is a program called cbw (for `crypt breakers workbench') which can automatically decrypt data encrypted with crypt[1]. After the war, the US government even sold Enigma cipher machines to third-world governments without telling them that they knew how to break this form of encryption. - Use of incorrectly-implemented algorithms. Some encryption programs use the DES algorithm, which consists of a series of complicated and arbitrary- seeming bit transformations controlled by complex lookup tables. These transformations and tables are very easy to get wrong. It is a property of the DES algorithm that even the slightest deviation from the correct implementation significantly weakens the algorithm itself. In other words any implementation which doesn't conform 100% to the standard may encrypt and decrypt data perfectly, but is in practice rather easier to break than the real thing. The US National Bureau of Standards (now the National Institute of Standards and Technology) provides a reference standard for DES encryption. A disappointingly large number of commercial implementations fail this test. - Use of badly-implemented algorithms. This is another problem which besets many DES implementations. DES can be used in several modes of operation, some of them better than others. The simplest of these is the Electronic Codebook (ECB) mode, in which a block of data is broken up into seperate subblocks which correspond to the unit of data which DES can encrypt or decrypt in one operation, and each subblock is then encrypted seperately. There also exist other modes such as CBC in which one block of encrypted data is chained to the next (such that the ciphertext block n depends not only on the corresponding plaintext but also on all preceding ciphertext blocks 0..n-1), and CFB, which is a means of converting a block cipher to a stream cipher with similar chaining properties. There are several forms of attack which can be used when an encrypted message consists of a large number of completely independant message blocks. It is often possible to identify by inspection repeated blocks of data, which may correspond to patterns like long strings of spaces in text. This can be used as the basis for a known-plaintext attack. ECB mode is also open to so-called message modification attacks. Lets assume that Bob asks his bank to deposit $10,000 in account number 12-3456-789012-3. The bank encrypts the message `Deposit $10,000 in account number 12-3456-789012-3' and sends it to its central office. Encrypted in ECB mode this looks as follows: E( Deposit $10,000 in acct. number 12-3456-789012-3 ) Bob intercepts this message, and records it. The encrypted message looks as follows: H+2nx/GHEKgvldSbqGQHbrUfotYFtUk6gS4CpMIuH7e2MPZCe Later on in the day, he intercepts the following a message: H+2nx/GHEKgvldSbqGQHbrUfotYFtUk61Pts2LtOHa8oaNWpj Since each block of text is completely independant of any surrounding block, he can simply insert the blocks corresponding to his account number: ................................gS4CpMIuH7e2MPZCe in place of the existing blocks, and thus alter the encrypted data without any knowledge of the encryption key used. Bob has since gone on to early retirement in his new Hawaiian villa. ECB mode, and the more secure modes such as CBC and CFB are described in several standards. Some of these standards make a reference to the insecurity of ECB mode, and recommend the use of the stronger CBC or CFB modes. Usually implementors stop reading at the section on ECB, with the result being that a number of commercial packages which use DES and which do manage to get it correct end up using it in ECB mode. - Protocol errors. Even if a more secure encryption mode such as CBC or CFB mode is used, there can still be problems. If a standard message format (such as the one shown above) is used, modification is still possible, except that now instead of changing individual parts of a message the entire message must be altered, since each piece of data is dependant on all previous parts. This can be avoided by prepending a random initialisation vector (IV) to each message, which propagates through the message itself to generate a completely different ciphertext each time the same message is encrypted. The use of the salt in Unix password encryption is an example of an IV, although the range of only 4096 values is too small to provide real security. In some ways, cryptography is like pharmaceuticals. Its integrity is important. Bad penicillin looks just the same as good penicillin. Determining whether most software is correct or not is simple - just look at the output. However the ciphertext produced by a weak encryption algorithm looks no different from the ciphertext produced by a strong algorithm.... until an opponent starts using your supposedly secure data against you, or you find your money transfers are ending up in an account somewhere in Switzerland, or financing Hawaiian villas. Footnote [1]: Available from ftp.ox.ac.uk in the directory /src/security as cbw.tar.Z. Security Analysis ----------------- This section attempts to analyse some of the possible failure modes of SFS and indicate which strategies have been used to minimise problems. Incorrect Encryption Algorithm Implementations When implementing something as complex as most encryption algorithms, it is very simple to make a minor mistake which greatly weakens the implementation. For example, making even the smallest change to the DES algorithm reduces its strength considerably. There is a body of test data available as US National Bureau of Standards (NBS, now NIST) special publication 500-20 which can be used to validate DES implementations. Unfortunately the programmers who produce many commercial DES implementations either don't know it exists or have never bothered using it to verify their code (see the section "Other Software" above), leading to the distribution of programs which perform some sort of encryption which is probably quite close to DES but which nevertheless has none of the security of the real DES. In order to avoid this problem, the SHS code used in SFS has a self-test feature which you can use to check that it conforms with the data given in Federal Information Processing Standards (FIPS) publication 180 and ANSI X9.30 part 2, which are the specifications for the SHS algorithm[1]. You can invoke the self-test in the mksfs program by using the `-t' test option: mksfs -t The other SFS programs and the SFS driver itself use exactly the same code, so testing it in mksfs is enough to ensure correctness of the other two programs. The following tests can take a minute or so to run to completion. The self-test, when run, produces the following output: Running SHS test 1 ... passed, result=0164B8A914CD2A5E74C4F7FF082C4D97F1EDF880 Running SHS test 2 ... passed, result=D2516EE1ACFA5BAF33DFC1C471E438449EF134C8 Running SHS test 3 ... passed, result=3232AFFA48628A26653B5AAA44541FD90D690603 You can compare the test results with the values given in Appendix 1 of the FIPS publication for correctness (mksfs will also print an error message if any of the tests fail). If the SHS implementation passes the self-test, mksfs will perform a speed test and display a message along the lines of: Testing speed for 10MB data... done. Time = 31 seconds, 323 kbytes/second All SHS tests passed Note that the speed given in this test is only vaguely representative of the actual speed, as the test code used slows the implementation down somewhat. In practice the overall speed should be higher than the figure given, while the actual disk encryption speed will be lower due to the extra overhead of disk reading and writing. Footnote [1]: The FIPS 180 publication is available from the National Technical Information Service, Springfield, Virginia 22161, for $22.50 + $3 shipping and handling within the US. NTIS will take telephone orders on +1 (703) 487-4650 (8:30 AM to 5:30 PM Eastern Time), fax +1 (703) 321-8547. For assistance, call +1 (703) 487-4679. Weak passwords Despite the best efforts of security specialists to educate users about the need to choose good keys, people persist in using very weak passwords to protect critical data. SFS attempts to ameliorate this problem by forcing a minimum key length of 10 characters and making a few simple checks for insecure passwords such as single word-word passwords (since the number of words of length 10 or more characters is rather small, it would allow a very fast dictionary check on all possible values). The checking is only rudimentary, but in combination with the minimum password length should succeed in weeding out most weak passwords. Another possible method to improve password security is to force a key to contain at least one punctuation character or at least one digit, as some Unix systems do. Unfortunately this tends to encourage people to simply append a token punctuation character or a fixed digit to the end of an existing key, with little increase in security. More password issues are discussed in the section "The Care and Feeding of Passwords" above. Data left in program memory by SFS programs Various SFS utilities make use of critical keying information which can be used to access an SFS volume. Great care has been taken to ensure that all critical information stored by these programs is erased from memory at the earliest possible moment. All encryption-related information is stored in static buffers which are accessed through pointers passed to various routines, and is overwritten as soon as it is no longer needed. All programs take great care to acquire keying information from the user at the last possible moment, and destroy this information as soon as either the disk volume has been encrypted or the keying information has been passed to the SFS driver. In addition, they install default exit handlers on startup which systematically erase all data areas used by the program, both for normal exits and for error or special-condition exits such as the user interrupting the programs execution. Data left in program memory by the SFS driver The SFS driver, in order to transparently encrypt and decrypt a volume, must at all times store the keying information needed to encrypt and decrypt the volume. It is essential that this information be destroyed as soon as the encrypted volume is unmounted. SFS does this by erasing all encryption-related information held by the driver as soon as it receives an unmount command. In addition, the driver's use of a unique disk key for each disk ensures that even if a complete running SFS system is captured by an opponent, only the keys for the volumes currently mounted will be compromised, even if several volumes are encrypted with the same user password (see the section "Password Lifetimes and Scope" below for more details on this). Data left in system buffers by mksfs mksfs must, when encrypting a volume, read and write data via standard system disk access routines. This data, consisting of raw disk sectors in either plaintext or encrypted form, can linger inside system buffers and operating system or hard disk caches for some time afterwards. However since none of the information is critical (the plaintext was available anyway moments before mksfs was run, and at worst knowledge of the plaintext form of a disk sector leads to a known plaintext attack, which is possible anyway with the highly regular disk layout used by most operating systems), and since accessing any of this information in order to erase it is highly nontrivial, this is not regarded as a weakness. Data left in system buffers by mountsfs As part of its normal operation, mountsfs must pass certain keying information to the SFS driver through a DOS system call. DOS itself does not copy the information, but simply passes a pointer to it to the SFS driver. After the driver has been initialised, mountsfs destroys the information as outlined above. This is the only time any keying information is passed outside the control of mountsfs, and the value is only passed by reference. Data left in system buffers by the SFS driver Like mksfs, the SFS driver reads and writes data via standard system disk access routines. This data, consisting of raw disk sectors in either plaintext or encrypted form, can linger inside system buffers and operating system or hard disk caches for some time afterwards. Once the encrypted volume is unmounted, it is essential that any plaintext information still held in system buffers be destroyed. In order to accomplish this, mountsfs, when issuing an unmount command, performs two actions intended to destroy any buffered information. First, it issues a cache flush command followed by a cache reset command to any DOS drive cacheing software it recognizes, such as older versions of Microsoft's SmartDrive (with IOCTL commands), newer versions of SmartDrive (version 4.0 and up), the PCTools 5.x cache, Central Point Software's PC-Cache 6.0 and up, the more recent PC-Cache 8.x, Norton Utilities' NCache-F, NCache-S, and the newer NCache 6.0 and up, Super PC-Kwik cache 3.0 and up, QuickCache II 4.20 and up, Qualitas' QCache 4.0 and up, and Future Computing Systems Fast! 4.02 and up. Some other cacheing software can be detected but doesn't support external cache flushing. This step is handled by mountsfs rather than the driver due to the rather complex nature of the procedures necessary to handle the large variety of cacheing software, and the fact that most cacheing software can't be accessed from a device drvier. After this the SFS driver itself issues a disk reset command which has the effect of flushing all buffered and cached data scheduled to be written to a disk, and of marking those cache and buffer entries as being available for immediate use. In addition to the explicit flushing performed by the mountsfs program, many cacheing programs will recognise this as a signal to flush their internal buffers (quite apart from the automatic flushing performed by the operating system and the drive controller). Any subsequent disk accesses will therefore overwrite any data still held in the cache and system buffers. While this does not provide a complete guarantee that the data has gone (some software disk caches will only support a cache flush, not a complete cache reset), it is the best which can be achieved without using highly hardware and system-specific code. SFS volumes left mounted It is possible that an SFS volume may be unintentionally left mounted on an unattended system, allowing free access to both the in-memory keying information and the encrypted volume. In order to lessen this problem somewhat, the SFS driver provides a fast-unmount hotkey which allows an unmount command to be issued instantly from the keyboard (see the sections "Mounting an SFS Volume" and "Advanced SFS Driver Options" above). The ease of use of this command (a single keystroke) is intended to encourage the unmounting of encrypted volumes as soon as they are no longer needed, rather than whenever the system is next powered down. The driver also provides an automatic timed-unmount facility to unmount volumes after they have been left idle for a predefined amount of time, so that volumes mistakenly left mounted while the system is unattended may be automatically unmounted. This ensures that, when the inevitable distractions occur, encrypted volumes are safely unmounted at some point rather than being left indefinitely accessible to anyone with access to the system. Finally, the driver provides the ability to unmount volumes when the smart card which controls them is removed from the card reader. As an extra precaution, the driver's use of a unique disk key for each disk ensures that even if a complete running SFS system with encrypted volumes still mounted is captured by an opponent, only the keys for the volumes currently mounted will be compromised, even if several volumes are encrypted with the same user password (more information on this is given in the section "Password Lifetimes and Scope" below). Password Lifetimes and Scope An SFS password which is used over a long period of time makes a very tempting target for an attacker. The longer a particular password is used, the greater the chance that it has been compromised. A password used for a year has a far greater chance of being compromised than one used for a day. If you use a password over a long period of time, the temptation for an attacker to spend the effort necessary to break it is far greater than if the password is only a short-term one. The scope of a password is also important. If you use a given password to encrypt a single drive containing business correspondence, it's compromise is only mildly serious. If you use it to protect dozens of disk volumes or a large file server holding considerable amounts of confidential information, the compromise of the password could be devastating. Again, the temptation to attack the master password for an entire file server is far greater than for a password protecting data contained on a single floppy disk. SFS approaches this problem in two ways. First, it uses unique disk keys to protect each SFS volume. The disk key is a 1024-bit cryptographically strong random key generated from nondeterministic values acquired from system hardware, system software, and user input (see the subsection "Generating Random Numbers" below). The data on each disk volume is encrypted using this unique disk key, which is stored in encrypted form in the SFS volume header (this works somewhat like session keys in PEM or PGP, except that a conventional-key algorithm is used instead of a public-key one). To access the disk, the encrypted disk key is first decrypted with the user password or key, and the disk key itself is used to access the disk. If the same user key were being used to access three encrypted volumes, it would look like this: + User - - - + + Encrypted volume 1 - - - - - - - - - - - - + | +--------+ | decrypt | +----------+ decrypt +--------------+ | |User Key| -----+-----> |Disk Key 1| -----------> |Encrypted Data| | +--------+ | | | +----------+ +--------------+ | | + - - - - - - + | + - - - - - - - - - - - - - - - - - - - - - - + | | + Encrypted volume 2 - - - - - - - - - - - - + | | | +----------+ decrypt +--------------+ | +-----> |Disk Key 2| -----------> |Encrypted Data| | | +----------+ +--------------+ | | | + - - - - - - - - - - - - - - - - - - - - - - + | | + Encrypted volume 3 - - - - - - - - - - - - + | | | +----------+ decrypt +--------------+ | +-----> |Disk Key 3| -----------> |Encrypted Data| | +----------+ +--------------+ | + - - - - - - - - - - - - - - - - - - - - - - + This scheme denies an attacker any known plaintext to work with (as the plaintext consists of the random disk key). To check whether a given password is valid, an attacker must use it to decrypt the disk key, rekey the encryption system with the decrypted disk key, and try to decrypt the disk data. Only then will they know whether their password guess was correct or not. This moves the target of an attack from a (possibly simple) user password to a 1024-bit random disk key[1]. In the above example, an attacker who had somehow broken the encryption to recover Disk Key 1 would still have no clue as to the identities of Disk Key 2 and Disk Key 3, even though all three volumes use the same user password. The other way in which SFS tries to ameliorate the problem of password lifetimes and scope is by making the changing of a password a very simple operation. Since the only thing which needs to be changed when a password change is made is the encryption of the disk key, you can change the password in a matter of seconds rather than the many minutes it would take to decrypt and re-encrypt an entire disk. Hopefully the ease with which passwords can be changed will encourage you to change passwords frequently. Footnote [1]: SFS may not use the entire 1024 bits - the exact usage depends on the encryption algorithm being used. Trojan Horses The general problem of trojan horses is discussed in the section "Data Security" above. In general, by planting a program in the target machine which monitors your password as it is entered or your data as it is read from or written to disk, an attacker can spare themselves the effort of attacking the encryption system itself. In an attempt to remove the threat of password interception, SFS takes direct control of the keyboard and various other pieces of system hardware which may be used to help intercept keyboard access, making it significantly more difficult for any monitoring software to detect passwords as they are entered. If any keystroke recording or monitoring routines are running, the SFS password entry process is entirely invisible to them. This feature has been tested by a computer security firm who examined SFS, and found it was the only program they had encountered (including one rated as secure for military use) which withstood this form of attack. Similarly, the fast disk access modes used by SFS can be used to bypass any monitoring software, as SFS takes direct control of the drive controller hardware rather than using the easily-intercepted BIOS or DOS disk access routines. Although these measures can still be worked around by an attacker, the methods required are by no means trivial and will probably be highly system-dependant, making a general encryption-defeating trojan horse difficult to achieve.